1. Field of the Invention
The present invention relates to a method and device for processing a routing information in a packet data network, such as an Internet Protocol (IP) Multimedia Subsystem (IMS) provided on top of a packet data network to offer voice and multimedia services e.g. for third generation mobile devices, or any other IP-based network.
2. Description of the Related Art
The Session Initiation Protocol (SIP) as defined in the Internet Engineering Task Force (IETF) specification RFC 3261, provides an emerging standard for setting up multimedia sessions on the Internet. Its basic capabilities are setup modification and tear down of any communication session, so it is a signaling protocol. SIP also provides personal mobility, meaning that a consumer is reachable via a single address regardless of its current point of attachment to the network.
In order to support multimedia services, seamless mobility and efficient multiparty conferencing, the IP layer has been enhanced. Mobile IP allows terminals to move freely between different mobile networks.
SIP is used to establish, modify and terminate sessions as well as send and receive transactions. It provides personal mobility by allowing a user to dynamically register to the network with his communication address, i.e. SIP URI (Uniform Resource Indicator). A session is usually a number of Real-time Transport Protocol (RTP) streams to be exchanged. Normally, a session is a combination of speech, audio and video streams, but it may also contain shared applications. A basic SIP network is composed of four types of elements i.e. User Agents (UA), Proxy Servers, Redirect Servers and Registrar Servers. User Agents typically reside in endpoints such as IP phones, personal computers or mobile devices. They initiate requests and provide responses. Usually, UAs also have an interface to media handling and to the actual application software providing the user interface. Proxy servers are intermediaries, which receive and forward requests providing them with, e.g., routing or other services. Redirect servers simply respond to a request by asking its originator to redirect it to a new address. Registrar servers keep track on the actual points of contact of the consumers by accepting registrations from the UAs. Registrar servers and the SIP registration procedure in general provide user mobility as the consumer is able to be reachable from any location via a single address. In this sense, they resemble Home Location Register (HLR) functionality in the Global System for Mobile communications (GSM) networks. Each consumer is part of a domain and each domain runs at least one registrar server, which knows the location of its consumers if the are registered.
SIP uses an address format common to Internet Mail, i.e. “user@domain”. The domain part is used to find the correct domain for the consumer and the user part is used to distinguish between individual consumers within a domain. SIP includes request and response messages comprising header fields, e.g. for defining where the request is to be sent next, the recipient address, the sender address etc. Furthermore, a SIP message may contain a payload portion for transmitting subscriber or service specific information.
Currently, the 3rd Generation Partnership Project (3GPP) is specifying IMS (IP Multimedia Subsystem) e.g. in its specification TS 23.228 as an access independent subsystem which can be used in connection with different networks. IMS uses SIP for session initiation. Basically IMS is just an instance of a SIP network. It has a number of proxies and a registrar. The UA is situated in the terminal device or user equipment (UE). When two devices establish a session they talk to each other via Call State Control Function or Call Session Control Function (CSCF) elements. The UE is connected to a Proxy-CSCF (P-CSCF) arranged in a visited domain of the UE and providing basic IP connectivity and mobile management below it. The UE uses SIP to communicate with the P-CSCF which is similar to a SIP proxy server. In such a case, the consumer or subscriber of the UE is roaming in the visited domain where the P-CSCF is located. The role of the P-CSCF is to provide emergency call and other such services requiring specific knowledge of the visited domain. In case the consumer or subscriber is not roaming the UE is connected to a P-CSCF located in the home domain. Instead of radio access network also alternative access networks may be used. Instead of mobile or cellular terminal device also other kind of terminals may be used, especially in alternative access networks.
Furthermore, an S-CSCF is always located in the subscriber's or consumer's home domain and takes the role of the SIP registrar and proxy servers, so that the UE can be registered at the S-CSCF using SIP via the P-CSCF. Furthermore, an I-CSCF is provided as another SIP proxy server responsible mainly for finding the correct S-CSCF for a given subscriber or consumer. The S-CSCFs can be dynamically allocated per registration in order to achieve efficient load balancing and error residency. An Application Server (AS) is provided as a SIP element dealing with the services provided to the UE. Separate ASs can be provided for different purposes. Finally, a Home Subscriber Server (HSS) is arranged for profile management and authentication.
In IMS, subsequent SIP messages follow the path recorded into a Record-Route header of the initial request, while interrogating network nodes may drop themselves out and other network elements stay on path. On the other hand, proxy servers in the middle may ask to remain on the signaling path for the duration of the call. This might be useful if the proxy offers some services to the call.
Topology Hiding, also known as Network or Configuration Hiding, allows an operator to hide the names and amount of the operator's SIP servers to another operator. Furthermore it hides the topology of the network. Topology Hiding is specified within the IMS (see e.g. 3GPP specification TS 23.228). Currently, a solution for it is described in the 3GPP specification TS 24.229, but this solution may lead to routing errors. Topology hiding can be applied by none, only one or both home networks, it cannot be applied by a visited network. The present invention applies to any case where at least one of the home networks applies topology hiding.
FIG. 1 shows a schematic block diagram of an exemplary IMS network architecture in which the present invention can be implemented. The SIP Proxies in the IMS are called CSCF, and for the discussed problem underlying the present invention the following CSCF types of FIG. 1 are of relevancy. A P-CSCF-A 20 is a SIP outbound proxy to which the mobile station UE-A 10 of User A is attached in its currently visited domain 70. Furthermore, an I-CSCF-A1 30 is provided as the I-CSCF between the P-CSCF-A 20 and an S-CSCF-A 40, and acts as a topology hiding gateway (THIG). The S-CSCF-A 40 is the SIP Proxy providing services, provided for example by an AS1 60 or other ASs (not shown), for User A in A's home network 72. Additionally, another I-CSCF-A2 34 is provided as the I-CSCF used by the S-CSCF-A 40 as the outgoing THIG when sending messages to the home network 82 of User B having a mobile station UE-B 12. The I-CSCF-A2 34 can also be the incoming THIG for messages from User B's home network 82. A further I-CSCF-B1 32 is arranged as the I-CSCF used by an S-CSCF-B 42 as the outgoing THIG when sending messages to the home network 72 of User A. The I-CSCF-B1 32 can also be the incoming THIG for messages from User A's home network 72. The S-CSCF-B 42 is the SIP Proxy providing services for User B in B's home network 82. Another I-CSCF-B2 is the I-CSCF between the S-CSCF-B 42 and a P-CSCF-B 22, and acts as a THIG. The P-CSCF-B 22 is the SIP outbound proxy to which the mobile station UE-B 12 of User B is attached in its visited network 80. I-CSCF and THIG functionalities may be implemented separately. They also may be named and/or combined with other functionalities differently when used in SIP or other types of networks based e.g. on the specification of 3GPP2 or IETF.
All SIP signaling within the IMS goes at least through these four SIP Proxies in the above listed order, whenever topology hiding is applied in both home networks.
It is to be noted here, that in the following “THIG” may be omitted in the notation “I-CSCF(THIG)” and “I-CSCF/THIG” for the sake of brevity. The latter case notation denotes the same as the corresponding former case notation, e.g., I-CSCF-B1(THIG) and I-CSCF-B1/THIG may be referred simply with i-cscf-b1.
In the following, the conventional mechanism for network hiding is described and a sequencing problem of Route headers is shown.
The current solution described in the 3GPP specification TS 24.229 works roughly in the following way:                all SIP messages (requests and responses) sent outside a users home network (either to the home network of the other user or the visited network of the served user) must traverse an I-CSCF/THIG in the users home network before leaving it;        the I-CSCF/THIG finds out all SIP URIs that were added by the home network to Via, Route, Record-Route, Path, Service-Route or any other header;        the I-CSCF/THIG applies an internal encryption mechanism and generates an encrypted name and/or address information which is called “token”.        
For example, the following header can be sent outside of User A's home network 72 and is received (e.g. in an INVITE request) by I-CSCF-A2 34 (indentions and line breaks as well as omission of branch parameter are just there for better readability):    [I] Via: SIP/2.0/UDP s-cscf-a.home1.net,            SIP/2.0/UDP i-cscf-a1.home1.net,        SIP/2.0/UDP p-cscf-a.visited1.net,        SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]        
The I-CSCF-A2 34 now selects the entries belonging to its home network, which are:                SIP/2.0/UDP s-cscf-a.home1.net        SIP/2.0/UDP i-cscf-a1.home1.netand hides them by generating a token (e.g. “1987klwkmlkmva98u4q5”) by whatever local encryption mechanism. For better readability the token is further on represented by the following string:        Token(SIP/2.0/UDP s-cscf-a.home1.net,                    SIP/2.0/UDP i-cscf-a1.home1.net)                        
The I-CSCF-A2 34 then forms a valid SIP Via header entry from the token and adds the tokenized-by tag:                SIP/2.0/UDP Token(SIP/2.0/UDP s-cscf-a.home1.net,                    SIP/2.0/UDPi-cscf-a1.home1.net)@home1.net;            tokenized-by=home1.netinserts it to the Via header and adds its own address:                            [II] Via: SIP/2.0/UDP i-cscf-a2.home1.net,            SIP/2.0/UDP Token(SIP/2.0/UDP s-cscf-a.home1.net,                    SIP/2.0/UDPi-cscf-1.home1.net)@home1.net;            tokenized-by=home1.net,                        SIP/2.0/UDP p-cscf-a.visited1.net,        SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]        
The request traverses the other SIP-elements, until it reaches the end user, which sends back a response. The response to the request is routed based on the Via-header, so the response at one point hits I-CSCF-A2 34, showing exactly the same entry as shown in [II]. In order to be able to route inside the home network 72, the I-CSCF-A2 34 selects all the entries which are indicated as “tokenized-by=home1.net” and decrypts them. Afterwards the Via-header looks again as in [I] and can be routed. Here there is no problem.
In the case of the Record-Route header, the same mechanism is applied, but it creates a problem.
User A sends a request to User B, the CSCFs put themselves into the Record-Route header, of which both users, when sending further requests that are related to this dialog (e.g. PRACK, UPDATE, BYE) form the Route header. User B sends back the Route header in the response to User A, so both have then the same route set.
However, when creating the Route for a new request, User A obtains a reversed order of the Record-Route header after decryption. It is noted that the request was sent to an application server (AS) of the network operator in home1.net and returned to the same S-CSCF, according to the conventional IMS service-procedures.
As an example, the Record-Route header as received in an INVITE request by User B might look as follows:    [III] Record-Route: p-cscf-b,            i-cscf-b2,        token(s-cscf-b,i-cscf-b1)@home2.net;tokenized-by=home2.net,        i-cscf-a2,        token (s-cscf-a,as1,s-cscf-a,i-cscf-a1)@home1.net;        tokenized-by=home1.net,        p-cscf-a        
Hence, the sent order can be represented as: 1, 2, (3,4), 5, (6,7,8,9), 10, where each number represents a specific one of the above servers or nodes passed during the routing procedure, and the numbers in brackets indicate tokenized or encrypted routes.
The Record-Route header is returned to User A in the response to the initial request. User A now wants to send e.g. the PRACK or any subsequent request or any other request along the recorded route, therefore it creates the Route header by simply reversing the order of the Record-Route entries, in accordance with the normal SIP procedure. Consequently, the Route header can be expressed as follows:    [IV] Route: p-cscf-a,            token(s-cscf-a,as1,s-cscf-a,i-cscf-a1)@home1.net;        tokenized-by=home1.net        i-cscf-a2,        token(s-cscf-b,i-cscf-b1)@home2.net;tokenized-by=home2.net,        i-cscf-b2,        p-cscf-b        
This routing order can be represented as: 10, (6,7,8,9), 5, (3,4), 2, 1.
The request will thus be sent to any I-CSCF in the home network, not to the I-CSCF-A1 30, which should be first on the route. This problem results from the fact that the entry of the I-CSCF-A1 30 has been maintained as encrypted by the I-CSCF-A2 34 when processing the initial request e.g. INVITE request.
However, this wrong order of entries within the tokens cannot be reversed by the UE, neither UE-A 10 nor UE-B 12, as the UE cannot look inside the token. When the first token is de-crypted, the entries will look like:    [V] Route: p-cscf-a,            s-cscf-a,        as1,        s-cscf-a,        i-cscf-a1,        i-cscf-a2,        ( . . . )which can be represented as: 10, 6, 7, 8, 9, 5, ( . . . ).        
However, the correct routing order should look like:    [VI] Route: p-cscf-a,            i-cscf-a1,        s-cscf-a,        as1,        s-cscf-a,        i-cscf-a2,        token(s-cscf-b,i-cscf-b1)@home2.net,tokenized-by=home2.net,        i-cscf-b2,        p-cscf-b            which can be represented as: 10, 9, 8, 7, 6, 5 ( . . . ).
Hence, the user is not capable to reverse the entries within tokens as the UE is not capable to look inside the tokens. Furthermore the request may then be sent to any I-CSCF in the home network, not specifically to the one, which should be the first on the route.